In an environment in which M2M devices are connected to an M2M service provider (SP) through an access network provided by another entity, the M2M service provider effectively creates a service layer on top of the access network. This service layer is used to deliver services to the M2M devices. Frameworks for providing M2M services have been developed by the European Telecommunications Standards Institute (ETSI) as well as by an organization known as oneM2M.
FIG. 1 illustrates the typical architecture of an M2M system as depicted in the ETSI specifications. According to the oneM2M architecture, an M2M system can be divided into a field domain, in which device gateways and M2M devices reside, and the infrastructure domain, where network-based functions reside. In each domain are application entities (AEs), shown as a Field Domain AE and an Infrastructure Domain AE in FIG. 1, as well as Common Services Entities (CSEs), shown as a Field Domain CSE and an Infrastructure Domain CSE. The AE provides application logic for specific end-to-end M2M solutions, such as for fleet tracking, remote power metering, etc. The CSE includes service functions that are common to the M2M environments and that are specified by oneM2M. These service functions are exposed to other entities through reference points Mca and Mcc. A network services entity (NSE) is also present in each domain, and is represented by a Field Domain NSE and an Infrastructure Domain NSE in FIG. 1. The NSE provides services such as device management, location services, and device triggering.
As part of its definition of the M2M architecture, oneM2M has defined several different types of nodes that it foresees as being part of the typical M2M network deployment. FIG. 2 illustrates some of these nodes. These nodes are functional/logical objects, and are not necessarily mapped to discrete physical devices, although any of them might be in any particular instance. One of these nodes is referred to as an Infrastructure Node (IN)—the IN resides in the Infrastructure Domain, contains one CSE, and may contain any number (including zero) of AEs. Typically, there would be just one IN in a deployment.
Another node is referred to as a Middle Node (MN)—a MN resides in the Field Domain, contains one CSE, and also may or may not contain one or more AEs. The functional/logical object known as the MN may reside in an M2M Gateway, for example. A MN can communicate with an IN and/or another MN and/or an Application Dedicated Node (ADN), which is a node that contains at least one AE but does not include a CSE.
Before a node can take advantage of services provided by the CSE of another node, it needs to register with that CSE. In the current oneM2M architecture, which is a distributed architecture, when an application registers with a CSE, it can create resources for storage in that CSE. These resources can be announced in other CSEs with a pointer back to the original resource. Resources stored in the CSE where the application registers can be read by other applications as long as it is allowed by the proper access control. Pointers to these resources are either discovered, or acquired by off-line means.